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(57) Abstract: An arbitration method and mechanism assigning priority to one of a combination of requesters. A priority vector 
for the combination of requesters has a sequential list of requester identifiers. Upon receiving requests from the combination of 
requesters, the corresponding priority vector is referred to and the next requester identifier on this list is selected. Priority is awarded 
to the requester corresponding to that requester identifier. A priority vector is preferably provided for each possible combination of 
multiple requesters. The list of requester identifiers in each priority vector may be advantageously programmable. Preferably, all 
requester identifiers for a single requester are not provided in a contiguous clump within a given priority vector. 
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Background of the Inventign 
The present invention relates to an arbitration mechanism lor awarding priority to 
one of a plurality of requesters, in particular, such a mechanism which guarantees a 
minimum software programmable slice of available bandwidth to each requestor. 
5 Where there is a single resource in the data processing system whether that 

resource be a bus, an SRAM, a FIFO, etc., an arbitrator is required to control access to 
that resource. In accordance with many arbitration schemes, each requestor has an 
assigned priority. Requesters with the same priority are given access in an equitable or 
round-robin fashion. Typically, requests with higher priority are given preferred access, 
10 preempting requests with lower priority. Additional mechanisms have been developed, 
that when added on top of such a system, prevent requesters with low priority from being 
starved from access to the resource. 

Summary of the Invention 

1 5 In accordance with an arbitration method embodiment of the invention, requests 

for access to a resource are received from a combination of requesters. A priority vector 
associated with that combination of requesters is referred to in order to identity the 
requestor to be awarded priority. Requestor identifiers each corresponding to one of the 
requesters are listed sequentially in the priority vector. The number of requestor 

20 identifiers in the vector exceed the number of requesters in the combination. A pointer 
identifies a next requester identifier on the list. The next requester identiHer is selected 
and the requester corresponding to that requester identifier is awarded priority. The 
pointer may be incremented sequentially through the list of requester identifiers. 
Programmability can be made available for the total number of requester identifiers in 

25 the priority vector and for the number of requester identifiers corresponding to each 
requester. 

According to a further embodiment of the arbitration method, a plurality of 
priority vectors are provided, one for each possible combination of multiple requesters 
that may seek access to the resource. The priority vector is a sequence of rcquesicr 

I 
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identifiers, each requester identifier corresponding to one of the requesters. When 
requests for access are received from the combination of requesters, the priority vector 
corresponding to the given combination of requesters is used for selection of the next 
requester identifier. Priority is awarded to the requester corresponding to the next 

5 requester identifier. 

In accordance with embodiments of an arbitration mechanism of the invention, a 
selector, responsive to requests for access from the requesters in a given combination of 
requesters, ascertains a next requester identifier from the sequence of requester 
identifiers in the priority vector corresponding to the given combination of requesters. 

10 Further, a pointer may be included for pointing to one of the requester identifiers in a 
priority vector. The sequence of requester identifiers may be held in a register. 

A data processing system embodiment of the invention includes a resource, a 
plurality of requesters and an arbiter in communication with the requesters. The arbiter 
includes a selector responsive to the requests for ascertaining a next requester identifier 

15 from an appropriate priority vector and awarding priority to the requester corresponding 
to a next requester identifier. 

Since each requester will have at least one requester identifier in the priority 
vector used to award priority, even low priority requesters, will be able to gain some 
minimal access to the resource. The ability to assign a percentage of bandwidth to each 

20 requester by adjusting the number of corresponding requester identifiers in priority 
vectors is an advantage of various embodiments of the invention. 

Other objects and advantages of the invention will become apparent during the 
following description of the presently prel'eiTed embodiments of the invention taken in 
conjunction with the drawings. 

25 

Brief Description of the Drawings 
FIG. 1 is a block diagram of a data processing system of an embodiment of the 
present invention. 

FIG. 2 is a schematic block diagram illustrating an arbitration method and 

1 
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mechanism of embodiments of the present invention. 

Detailed Description of the Preferred Embodiments 
Referring now to FIG. 1, in the data processing system 10 it is often the case that 

5 a plurality of requesters 12 may at the same time request access to a single resource 14. 
The resource may be any of a variety of components such as a bus, an SRAM, a FIFO, a 
network communication port, a graphic processing pipeline, DRAM memory banks, a 
data structure in a data base program, etc. In order to decide which requester receives 
access to the single resource 14, an arbiter 16 is provided. 

10 Arbiter 16 receives requests for access from any of a number of requesters. The 

arbiter 16 awards priority to one of the requesters. In a preferred embodiment, arbiter 16 
sends a select signal to multiplexor 18 which selects the data from the requester awarded 
priority. The selected data proceeds to the resource 14. Also in this embodiment, arbiter 
16 informs the requester awarded priority that its request was granted. Preferably, the 

15 arbiter is programmable. A processor 19 is shown for configuring the arbiter through a 
bus 17. 

A preferred embodiment of an arbiter of the present invention is illustrated in 
FIG. 2. The arbitration method is required when more than one requester 12 seeks 
access to a single resource at one time. For any given combination of requesters, the 

20 arbiter 16 has a priority vector 21 with a sequential list of requester identifiers. A 

requester identifier corresponds to one of the requesters. In a preferred embodiment, the 
number of requester identifiers in the list of the priority vector 2 1 exceeds the number of 
requesters in the given combination. In accordance with further embodiments, each 
possible combination of multiple requesters is associated with a priority vector 21. For 

25 each priority vector 2 1 , a pointer 24 or equivalent designator identifies the next requester 
identifier on the list. For the given combination of multiple requesters, the associated 
priority vector is referred to and the next requester identifier from that priority vector is 
selected. Priority is awarded to the requester corresponding to the next requester 
identiller. The pointer 24 is then changed to point to the next requester identifier along 

3 
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Ihe sequence of requester identifiers. As described, the arbitration method may be 
performed entirely in software or in a combination of software and hardware as 
described below with respect to FIG, 2. 

The arbitration mechanism includes a selector responsive to requests for access. 

5 The selector is responsible for ascertaining the next requester identifier in the appropriate 
priority vector for awarding priority to the requester corresponding to the next requester 
identifier. The selector in FIG. 2 includes a multiplexor 20 for selecting the appropriate 
priority vector and a multiplexor 22 for selecting the appropriate pointer The 
multiplexor 20 receives an input for each possible requester indicating whether a request 

10 is pending for the single resource. The embodiment shown is for a system with a 
maximum of three requesters. Therefore, there is a priority vector 21 for all three 
requesters and three additional priority vectors 21 for each possible combination of two 
requesters. Based on which requesters have requests pending, the multiplexor 20 
immediately selects the corresponding priority vector 2 1 . In the example of the 

15 illustration, the first and second requesters have pending requests and the priority vector 
for requester 1 and requester 2 is selected. 

Priority is awarded to the requester corresponding to the next requester identifier 
in the priority vector. The priority vector is a sequential list of requester identifiers, each 
requester identifier corresponding to one of the requesters. In the illustration, the 

20 requester identifier is simply the number 1 , 2 or 3 corresponding respectively to 

requester 1, requester 2 or requester 3. In the priority vector for requester 1 and requester 
2, the list includes requester identifiers corresponding to the two requesters 1 and 2. In 
the illustration, the priority vector for requester I and 2 split the priority 50/50 between 
requester 1 and requester 2, each one having five requester identifiers in the list. In the 

25 case where a requester has more than one requester identifier in the list, it is desirable not 
to clump all of its requester identifiers together as such arrangement may inordinately 
starve the other requester(s) out over a clump of time. Instead, it is prelerrcd for each 
requester having more than one requester identifier, that its requester identifiers not be 
contiguous all to one another. This distributes the grant of priority to the various 

4 
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requesters more evenly over time. 

The next requester identifier in a priority vector is indicated by a pointer 24. The 
multiplexor 22 receives the inputs indicating which requesters have a pending request 
and uses those inputs to immediately select the pointer corresponding to the selected 
5 priority vector. The pointer 24 is used to ascertain the next requester identifier which in 
turn determines which requester is awarded priority. The award of priority is signaled 
back to the requester so it knows its request is granted. The award of priority is also 
used by the resource to select the winning request and process it In FIG. 1, this is 
through multiplexor 1 8. Upon using a pointer 24 to select the award of priority, the 
10 pointer needs to be shifted to point to the following requester identifier on the priority 
vector. This may be accomplished by simply incrementing the pointer. A vector length 
indicator (numslot) 26 accompanies the pointer for each priority vector. When the total 
number of requester identifiers in the priority vector have been traversed by the pointer 
as determined by the vector length indicator, the pointer will wrap around to the first 
15 requester identifier on the list. A pointer control module 28 receives the pointer and 
associated vector length indicator 26 so as to generate the next pointer value and 
substitute it into the pointer 24. The pointer control module 28 can be formed in 
hardware, software or anything in between. 

In accordance with an embodiment of the present invention, the number of 
20 requester identifiers in the priority vector exceeds the number of requesters. Thus, for a 
system with three possible requesters, the priority vector for all three requesters exceeds 
three requester identifiers. The more requester identifiers in a priority vector, the smaller 
the minimum bandwidth which can be assigned lo a low priority requester. A priority 
vector with 10 requester identifiers can assign as little as one requester identifier to a 
25 requCvSter giving it approximately a 10% bandwidth. A priority vector with 16 requester 
identifiers permits assigning a bandwidth as small as about 6% to a low priority 
requester. 

Ln accordance with an embodiment of the invention, the number of requester 
identifiers in any given priority vector is programmable. Software instructions can be 

5 
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used lo set the vector length tor each of the priority vectors. Further progamni ability is 
also available in that the proportion of requester identifiers assigned to the requesters can 
be varied Ibr each priority vector. Although each priority vector can be individually 
programmed with a desired sequence and proportion of requester identifiers, it is 

5 generally preferable to determine a desired percentage bandwidth for each requester and 
have the various priority vectors attempt to achieve that goal. A system that desires to 
provide about 40% access to requester I, about 40% access to requester 2 and about 20% 
access to requester 3 with a vector length of 10 for each priority vector is shown in FIG. 
2. The priority vector for all three provides four requester identifiers for requester 1, 

10 four requester identifiers for requester 2 and two requester identifiers for requester 3. 
The priority vector for requesters I and 2 correspondingly provide five requester 

identifiers for requester 1 and five requester identifiers for requester 2. The priority ..m 

vector for requesters 1 and 3 provides six requester identifiers for requester 1 and four 

requester identifiers for requester 3. Similarly the priority vector for requesters 2 and 3 . . . ' 

15 provide six requester identifiers for requester 2 and four requester identifiers for 

requesters. One might also have chosen to divide these vectors seven to three rather r^rr. 
than six to four. As there are a small finite number of requester identifiers, bandwidth is 
only proportioned approximately. Increasing vector length can make the proportions :h: 
more precise. Although it is preferred to have consistency of proportions among the 

20 priority vectors, it is within the scope of the invention that each priority vector be 
independently programmed with its own list of requester identifiers without regard to 
overall proportions. Each requester can thus be given a desired number of requester 
identifiers in the priority vectors. In each priority vector, the requester identifiers for any 
given requester are preferably spread across the vector and do not appear in a single 

25 contiguous clump. 

The arbiter 16 of a presently preferred embodiment can be implemented on an 
ASIC. The priority vectors may be stored in a register. Each register may be divided 
into fields. One field provides slots that are filled by the requester identifiers to form 
priority vectors. A second field indicates Ihe vector length, i.e., the number of slots that 

6 
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are filled With requester identifiers. A large register can hold several priority vectors in 
separate fields and have associated fields which indicate the vector lengths for the 
corresponding priority vectors. The contents of the registers are programmable and may 
be filled to satisfy the requirements of a user through a processor 19 for example. 

5 Although shown and described with respect to hardware such as the multiplexors and 
registers, embodiments of the invention may also be made implementing aspects of the 
invention in software. 

Although tiie embodiments hereinbefore described are preferred, many 
modifications and refinements which do not depart from the true spirit and scope of the 

10 invention may be conceived by those skilled in the art. For example, the requester 
identifiers need not be numbers that match their corresponding requester but may be 
assigned via any desired coding. Shifting the pointer along a priority vector may involve 
any of incrementing, decrementing or other algorithm for moving the pointer in sequence 
through a list of requester identifiers. It is intended that all such modifications, including 

15 but not limited to those set forth above, be covered by the following claims. 
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WE CLAIM: 

1 . A method of arbitrating requests for access to a resource for use in a data 
processing system having a plurality of requesters and the resource, said method 
comprising: 

5 receiving requests for access from a combination of said requesters; 

referring to a priority vector associated with said combination of requesters, each 
priority vector having a sequential list of requester identifiers, the number of requester 
identifiers in the list exceeding the number of requesters in said combination, and a 
pointer to a next requester identifier on the list; 
1 0 selecting the next requester identifier from the priority vector associated with said 

combination of requesters; and 

awarding priority to the requester corresponding to the next requester identifier. 

2. The method of claim 1 further comprising setting the number of requester 
1 5 identifiers in the priority vector. 

3. The method of claim 2 further comprising setting how many of the requester 
identifiers correspond to each requester in the combination of requesters associated with 
the priority vector. 

20 

4. The method of claim 3 wherein for those requesters having a plurality of 
requester 

identifiers in the priority vector, the corresponding requester identifiers for each of those 
requesters not all being contiguous in the sequential list. 

25 

5. The method of claim I wherein said act of referring comprises identifying from 
among a plurality of priority vectors, the priority vector associated with said combination 
of requesters. 
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6. The method of claim I comprising sequentially changing the pointer along the 
sequence of requester identifiers each time a next requester identifier is selected. 

7. A method of arbitrating requests for access to a resource for use in a data 
5 processing system having a plurality of requesters and the resource, said method 

comprising: 

providing a plurality of priority vectors, one priority vector for each possible 
combination of multiple requesters seeking access to the resource, each vector being a 
sequence of requester identifiers, each requester identifier corresponding to one of the 
10 requesters; 

receiving requests for access to the resource from a given combination of said 
requesters; 

selecting a next requester identifier from the priority vector corresponding to the 
given combination of requesters; 
15 awarding priority to the requester corresponding to the next requester identifier. 

8. The method of claim 7 further comprising assigning each requester in the 
combination of requesters corresponding to one of the priority vectors a chosen number 
of requester identifiers in the priority vector. 

20 

9. The method of claim 8 wherein for those requesters having a chosen number 
greater than one for one of said priority vectors, the corresponding requester identifiers 
for each of those requesters not all being contiguous in the sequence of requester 
identifiers. 

25 

10. The method of claim 7 further comprising providing a pointer for each priority 
vector that points to the next requester identifier in the priority vector and sequentially 
changes along the sequence of requester identifiers each time a next requester identifier 
is selected. 

y 
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11. A method lor providing at least minimal access to a resource for each requester 
among a plurality of requesters, said method comprising: 

providing a plurality of priority vectors, each priority vector corresponding to a 
3 possible combination of said requesters and being capable of holding a set number of 
requester identifiers in a sequence; 

programming each priority vector such that it contains a desired number of 
requester identifiers corresponding to each of the requesters in the corresponding 
combination of requesters; 
10 pointing to a next requester identifier in each of said priority vectors; 

awarding priority to a requester from a combination of said requesters by 
identifying the next requester in the priority vector corresponding to the combination of 
requesters and pointing to a requester identifier following the next requester identifier in 
the sequence of said priority vector. 

15 

1 2. The method of claim 1 1 wherein for each requester having a number of requester 
identifiers greater than one in one of said priority vectors, the corresponding requester :; 
identifiers not all being contiguous in the sequence of requester identifiers of said one of s 
said priority vectors. 

20 

1 3. The method of claim 1 1 further comprising programming the set number of 
requester identifiers for each priority vector. 

14. The method of claim 1 1 wherein pointing to a requester identifier following the 
25 next requester identifier is performed in a wrap around manner upon reaching the end of 

the sequence. 

15. An arbitration mechanism for arbitrating requests for access to a resource 
comprising: 

10 
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a plurality of priority vectors, each providing a sequence of requester identifiers 
corresponding to requesters, the requester identifiers in each priority vector 
corresponding to requesters forming a different combination of requesters; 

a selector, responsive to requests Ibr access from the requesters in a given 
5 combination of requesters, for ascertaining a next requester identifier in sequence in the 
priority vector corresponding to the given combination of requesters and awarding 
priority to the requester corresponding to the next requester identifier. 

16. The arbitration mechanism of claim 15 wherein each priority vector has a number 
1 0 of requester identifiers exceeding the number of requesters in the respective combination 

of requesters. 

17. The arbitration mechanism of claim 15 wherein for each requester having a 
number of requester identifiers greater than one in one of said priority vectors, the 

15 corresponding requester identifiers not all being contiguous in the sequence of requester 
identifiers of said one of said priority vectors. 

1 8. The arbitration mechanism of claim 1 5 further comprising a processor that sets 
the total number of requester identifiers in each priority vector and sets the number of 

20 requester identifiers corresponding to any given requester in each priority vector. 

19. An arbitration mechanism comprising: 

a register for holding a sequence of requester identifiers, said register including 
requester identifiers corresponding to each requestor of a combination of requesters, 
25 wherein the number of requester identifiers in said register exceeds the number of 
requesters in said combination; 

a pointer for pointing to one of the requester identifiers in said register; and 
a selector, responsive to requests Irom the requesters in the combination of 
requesters. Tor awarding priority to the requester corresponding to the requester identifier 

11 
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being pointed at by said pointer; and 

means for shifting said pointer along the sequence of requester identifiers. 

20. The arbitration mechanism of claim 19 wherein said pointer shifts sequentially 
5 through said sequence of requester identifiers in a wrap around manner. 

21 . The arbitration mechanism of claim 19 further comprising a plurality of said 
registers, each including requester identifiers corresponding to a different combination of 
requesters. 

0 

22. The arbitration mechanism of claim 21 wherein said selector responds to 
requests from a given combination of requesters by awarding priority using the register 
having requester identifiers corresponding to the given combination of requesters. 

23. A data processing system comprising: 
a resource; 

a plurality of requesters; 

an arbiter in communication with said plurality of requesters, said arbiter 
including: 

a plurality of priority vectors, each providing a sequence of requester 
identifiers, each requester identifier corresponding to one of said requesters, the 
requester identifiers in each priority vector corresponding to requesters from a 
different combination of requesters; 

a selector, responsive to requests for access from the requesters in 
a given combination of said requesters, for ascertaining a next requester 
identifier in sequence in the priority vector corresponding to the given 
combination of requesters and awarding priority to the requester 
corresponding to the next requester identifier. 

30 24. The data processing system of claim 23 wherein each priority vector has a 

12 
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number of requester identifiers exceeding the number of requesters in the respective 
combination of requesters. 

25. The data processing system of claim 23 wherein for each requester having a 
5 number of requester identifiers greater than one in one of said priority vectors, the 

corresponding requester identifiers not all being contiguous in the sequence of requester 
identifiers of said one of said priority vectors. 

26. The data processing system of claim 23 further comprising a processor that sets 
10 the total number of requester identifiers in each priority vector and sets the number of 

requester identifiers corresponding to any given requester in each priority vector. 
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ARBITRATION METHOD AND APPARATUS 
Background of the Invention 

5 The present invention relates to an arbitration mechanism for awarding priority to 

one of a plurality of requesters, in particular, such a mechanism which guarantees a 
minimum software programmable slice of available bandwidth to each requestor. 

Where there is a single resource in the data processing system whether that 
resource be a bus, an SRAM, a FIFO, etc., an arbitrator is required to control access to 

10 that resource. In accordance with many arbitration schemes, each requestor has an 

assigned priority. Requesters with the same priority are given access in an equitable or 
round-robin fashion. Typically, requests with higher priority are given preferred access, 
preempting requests with lower priority. Additional mechanisms have been developed, 
that when added on top of such a system, prevent requesters with low priority from being 

15 starved from access to the resource. 

Summary of the Invention 

In accordance with an arbitration method embodiment of the invention, requests 
20 for access to a resource are received from a combination of requesters. A priority vector 
associated with that combination of requesters is referred to in order to identify the 
requestor to be awarded priority. Requestor identifiers each corresponding to one of the 
requesters are listed sequentially in the priority vector. The number of requestor 
identifiers in the vector exceed the number of requesters in the combination. A pointer 
25 identifies a next requester identifier on the list. The next requester identifier is selected 
and the requester corresponding to ttiat requester identifier is awarded priority. The 
pointer may be incremented sequentially through the list of requester identifiers. 
Programmability can be made available for the total number of requester identifiers in the 
priority vector and for the number of requester identifiers corresponding to each 
30 requester. 

According to a further embodiment of the arbitration method, a plurality of 
priority vectors are provided, one for each possible combination of multiple requesters 
that may seek access to the resource. The priority vector is a sequence of requester 
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identifiers, each requester identifier corresponding to one of the requesters. When 
requests for access are received from the combination of requesters, the priority vector 
corresponding to the given combination of requesters is used for selection of the next 
requester identifier. Priority is awarded to the requester corresponding to the next 

5 requester identifier. 

In accordance with embodiments of an arbitration mechanism of the invention, a 
selector, responsive to requests for access from the requesters in a given combination of 
requesters, ascertains a next requester identifier from the sequence of requester 
identifiers in the priority vector corresponding to the given combination of requesters. 

10 Further, a pointer may be included for pointing to one of the requester identifiers in a 
priority vector. The sequence of requester identifiers may be held in a register. 

A data processing system embodiment of the invention includes a resource, a 
plurality of requesters and an arbiter in communication with the requesters. The arbiter 
includes a selector responsive to the requests for ascertaining a next requester identifier 

1 5 from an appropriate priority vector and awarding priority to the requester corresponding 
to a next requester identifier. 

Since each requester will have at least one requester identifier in the priority 
vector used to award priority, even low priority requesters, will be able to gain some <i- 
minimal access to the resource. The ability to assign a percentage of bandwidth to each 

20 requester by adjusting the number of corresponding requester identifiers in priority 
vectors is an advantage of various embodiments of the invention. 

Other objects and advantages of the invention wiU become apparent during the 
following description of the presenfly preferred embodiments of the invention taken in 
conjunction with the drawings. 

25 

Brief Description of the Drawings 
FIG. 1 is a block diagram of a data processing system of an embodiment of the 
present iavention. 

FIG. 2 is a schematic block diagram illustrating an arbitration method and 

2 
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mechanism of embodiments of the present invention. 

Pfttailed Description of the Preferred Embodiments 
Referring now to FIG. 1, in the data processing system 10 it is often the case that 

5 a plurality of requesters 12 may at the same time request access to a single resource 14. 
The resource may be any of a variety of components such as a bus, an SRAM, a FIFO, a 
network communication port, a graphic processing pipeline, DRAM memory banks, a 
data structure in a data base program, etc. In order to decide which requester receives 
access to the single resource 14, an arbiter 16 is provided. 

10 Arbiter 16 receives requests for access from any of a number of requesters. The 

arbiter 16 awards priority to one of the requesters. In a preferred embodiment, arbiter 16 
sends a select signal to multiplexor 18 which selects the data from the requester awarded 
priority. The selected data proceeds to the resource 14. Also in this embodiment, arbiter 
16 informs the requester awarded priority that its request was granted. Preferably, the 

15 arbiter is progranunable. A processor 19 is shown for configuring the arbiter tiirough a 
bus 17. 

A preferred embodiment of an arbiter of the present invention is illustrated in 
FIG. 2. The arbitration method is required when more than one requester 12 seeks 
access to a single resource at one time. For any given combination of requesters, the 

20 arbiter 16 has a priority vector 21 with a sequential list of requester identifiers. A 

requester identifier corresponds to one of the requesters. In a preferred embodiment, the 
number of requester identifiers in the list of the priority vector 21exceeds the niunber of 
requesters in the given combination. In accordance with ftirflier embodiments, each 
possible combination of multiple requesters is associated with a priority vector 21. For 

25 each priority vector 21, a pointer 24 or equivalent designator identifies the next requester 
identifier on the list. For the given combination of multiple requesters, the associated 
priority vector is referred to and the next requester identifier from that priority vector is 
selected. Priority is awarded to the requester corresponding to the next requester 
identifier. The pointer 24 is then changed to point to the next requester identifier along 

3 
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the sequence of requester identifiers. As described, the arbitration method may be 
performed entirely in software or in a combination of software and hardware as 
described below with respect to FIG. 2. 

The arbitration mechanism includes a selector responsive to requests for access. 
5 The selector is responsible for ascertaining the next requester identifier in the appropriate 
priority vector for awarding priority to the requester corresponding to the next requester 
identifier. The selector in FIG. 2 includes a multiplexor 20 for selecting the appropriate 
priority vector and a multiplexor 22 for selecting the appropriate pointer. The 
multiplexor 20 receives an input for each possible requester indicating whether a request 
10 is pending for the single resource. The embodiment shown is for a system with a 
maximum of three requesters. Therefore, there is a priority vector 21 for all three 
requesters and three additional priority vectors 21 for each possible combination of two - • 
requesters. Based on which requesters have requests pending, the multiplexor 20 r; 
immediately selects the corresponding priority vector 21 , In the example of the ? 
15 illustration, the first and second requesters have pending requests and the priority vector 
for requester 1 and requester 2 is selected. 

Priority is awarded to the requester corresponding to the next requester identifier : . 
in the priority vector. The priority vector is a sequential list of requester identifiers, each- 
requester identifier corresponding to one of the requesters. In the illustration, the 
20 requester identifier is simply the number 1, 2 or 3 corresponding respectively to 

requester 1, requester 2 or requester 3. In the priority vector for requester 1 and requester 
2, the list includes requester identifiers corresponding to the two requesters 1 and 2. In 
the illustration, the priority vector for requester 1 and 2 split the priority 50/50 between 
requester 1 and requester 2, each one having five requester identifiers in the list. In the 
25 case where a requester has more than one requester identifier in the list, it is desirable not 
to clump all of its requester identifiers together as such arrangement may inordinately 
starve the other requester(s) out over a clump of time. Instead, it is preferred for each 
requester having more than one requester identifier, that its requester identifiers not be 
contiguous all to one another. This distributes the grant of priority to the various 
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requesters more evenly over time. 

Hie next requester identifier in a priority vector is indicated by a pointer 24. The 
multiplexor 22 receives the inputs indicating which requesters have a pending request 
and uses those inputs to immediately select the pointer corresponding to the selected 
5 priority vector. The pointer 24 is used to ascertain the next requester identifier which in 
turn determines which requester is awarded priority. The award of priority is signaled 
back to the requester so it knows its request is granted. The award of priority is also 
used by the resovirce to select the wiiming request and process it In FIG. 1, this is 
through multiplexor 18. Upon using a pointer 24 to select the award of priority, the 
10 pointer needs to be shifted to point to the following requester identifier on the priority 
vector. This may be accomplished by simply incrementing the pointer. A vector length 
indicator (numslot) 26 accompanies the pointer for each priority vector. When the total 
number of requester identifiers in the priority vector have been traversed by the pointer 
as determined by the vector length indicator, the pointer will wrap aromd to the first 
1 5 requester identifier on the list. A pointer control module 28 receives the pointer and 
associated vector length indicator 26 so as to generate the next pointer value and 
. substitute it into the pointer 24. The pointer control module 28 can be formed in 
hardware, software or anything in between. 

In accordance with an embodiment of the present invention, the number of 
20 requester identifiers in the priority vector exceeds the number of requesters. Thus, for a 
system with three possible requesters, the priority vector for all three requesters exceeds 
three requester identifiers. The more requester identifiers in a priority vector, the smsdler 
the mminrnm bandwidth which can be assigned to a low priority requester. A priority 
vector with 10 requester identifiers can assign as little as one requester identifier to a 
25 requester giving it approximately a 10% bandwidth. A priority vector with 16 requester 
identifiers permits assigning a bandwidth as small as about 6% to a low priority 
requester. 

In accordance with an embodiment of the invention, the number of requester 
identifiers in any given priority vector is programmable. Software instructions can be 
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used to set the vector length for each of the priority vectors. Further progammability is 
also available in that the proportion of requester identifiers assigned to the requesters can 
be varied for each priority vector. Although each priority vector can be individually 
progranuned with a desired sequence and proportion of requester identifiers, it is 

5 generally preferable to detennine a desired percentage bandwidth for each requester and 
have the various priority vectors attempt to achieve that goal. A system that desires to 
provide about 40% access to requester 1, about 40% access to requester 2 and about 20% 
access to requester 3 with a vector length of 10 for each priority vector is shown in FIG. 
2. The priority vector for all three provides four requester identifiers for requester 1 , 

10 four requester identifiers for requester 2 and two requester identifiers for requester 3. 
The priority vector for requesters 1 and 2 correspondingly provide five requester 
• identifiers for requester 1 and five requester identifiers for requester 2. The priority, 
vector for requesters 1 and 3 provides six requester identifiers for requester 1 and four 
requester identifiers for requester 3. Similarly the priority vector for requesters 2 and 3 

15 provide six requester identifiers for requester 2 and four requester identifiers for 

requester 3. One might also have chosen to divide these vectors seven to three rather 
than six to four. As there are a small finite number of requester identifiers, bandwidth is 
only proportioned approximately. Increasing vector length can make the proportions 
more precise. Although it is preferred to have consistency of proportions among the 

20 priority vectors, it is within the scope of the invention that each priority vector be 
independentiy programmed with its own list of requester identifiers without regard to 
overall proportions. Each requester can thus be given a desired number of requester 
identifiers in the priority vectors. In each priority vector, the requester identifiers for any 
given requester are preferably spread across the vector and do not appear in a single 

25 contiguous clump. 

The arbiter 16 of a presentiy preferred embodiment can be implemented on an 
ASIC. The priority vectors may be stored in a register. Each register may be divided 
into fields. One field provides slots that are filled by the requester identifiers to form 
priority vectors. A second field indicates tlie vector length, i.e., the number of slots that 

6 
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are filled with requester identifiers- A large register can hold several priority vectors in 
separate fields and have associated fields which indicate the vector lengths for the 
corresponding priority vectors. The contents of the registers are programmable and may 
be filled to satisfy the requirements of a user through a processor 19 for example. 

5 Although shown and described with respect to hardware such as the multiplexors and 
registers, embodiments of the invention may also be made implementing aspects of the 
invention in software. 

Although the embodiments hereinbefore described are preferred, many 
modifications and refinements which do not depart firom the true spirit and scope of the 

10 invention may be conceived by those skilled in the art For example, the requester 
identifiers need not be numbers that match their corresponding requester but may be 
assigned via any desired coding. Shifting the pointer along a priority vector may involve 
any of incrementing, decrementing or other algorithm for moving the pointer in sequence 
through a list of requester identifiers. It is intended that all such modifications, including 

15 but not limited to those set forth above, be covered by the following claims. 
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WE CLAIM: 

1. A method of arbitrating requests for access to a resource for use in a data 
processing system having a plurality of requesters and the resource, said method 
comprising: 

5 receiving requests for access from a combination of said requesters; 

referring to a priority vector associated with said combination of requesters, each 
priority vector having a sequential list of requester identifiers, the number of requester 
identifiers in the list exceeding the number of requesters in said combination, and a 
pointer to a next requester identifier on the list; 
10 selecting the next requester identifier from the priority vector associated with said 

combination of requesters; and 

awarding priority to the requester corresponding to the next requester identifier. . 

2. The method of claim 1 further comprising setting the number of requester 
1 5 identifiers in the priority vector, 

3. The method of claim 2 further comprising setting how many of the requester 
identifiers correspond to each requester in the combination of requesters associated with 
the priority vector. 

20 

4. The method of claim 3 wherein for those requesters having a plurality of 
requester 

identifiers in the priority vector, the corresponding requester identifiers for each of those 
requesters not all being contiguous in the sequential list 

25 

5. The method of claim 1 wherein said act of referring comprises identifying from 
among a plurality of priority vectors, the priority vector associated with said combination 
of requesters. 
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6. The method of claim 1 comprising sequentially changing the pointer along the 
sequence of requester identifiers each time a next requester identifier is selected. 

7 . A method of arbitrating requests for access to a resource for use in a data 
5 processing system having a plurality of requesters and the resource, said method 

comprising: 

providing a plurality of priority vectors, one priority vector for each possible 
combination of multiple requesters seeking access to the resource, each vector being a 
sequence of requester identifiers, each requester identifier corresponding to one of the 
10 requesters; 

receiving requests for access to the resource from a given combination of said 
requesters; 

selecting a next requester identifier from the priority vector corresponding to the 
given combination of requesters; 
15 awarding priority to the requester corresponding to the next requester identifier. 

8. The method of claim 7 further comprising assigning each requester in the 
combination of requesters corresponding to one of the priority vectors a chosen number 
of requester identifiers in the priority vector. 

20 

9. The method of claim 8 wherein for those requesters having a chosen number 
greater than one for one of said priority vectors, the corresponding requester identifiers 
for each of those requesters not all being contiguous in the sequence of requester 
identifiers. 

25 

10. The method of claim 7 further comprising providing a pointer for each priority 
vector that points to the next requester identifier in the priority vector and sequentially 
changes along tiie sequence of requester identifiers each time a next requester identifier 
is selected. 
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11. A method for providing at least minimal access to a resource for each requester 
among a plurality of requesters, said method comprising: 

providing a plurality of priority vectors, each priority vector corresponding to a 
5 possible combination of said requesters and being capable of holding a set number of 
requester identifiers in a sequence; 

programming each priority vector such that it contains a desired number of 
requester identifiers corresponding to each of the requesters in the corresponding 
combination of requesters; ' 
10 pointing to a next requester identifier in each of said priority vectors; 

awarding priority to a requester from a combination of said requesters by 
identifying the next requester in the priority vector corresponding to the combination of 
requesters and pointing to a requester identifier following the next requester identifier in , , 
the sequence of said priority vector. 

15 

12. The method of claim 1 1 wherein for each requester having a number of requester 
identifiers greater than one in one of said priority vectors, the corresponding requester 
identifiers not all being contiguous in the sequence of requester identifiers of said one of y 
said priority vectors. 

20 

13. The method of claim 1 1 further comprising programming the set number of 
requester identifiers for each priority vector. 

14. The method of claim 1 1 wherein pointing to a requester identifier following the 
25 next requester identifier is performed in a wrap around manner upon reaching the end of 

the sequence. 

15. An arbitration mechanism for arbitrating requests for access to a resource 
comprising: 

10 
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a plurality of priority vectors, each providing a sequence of requester identifiers 
corresponding to requesters, the requester identifiers in each priority vector 
corresponding to requesters forming a different combination of requesters; 

a selector, responsive to requests for access from the requesters in a given 
5 combination of requesters, for ascertaining a next requester identifier in sequence in the 
priority vector corresponding to the given combination of requesters and awarding 
priority to the requester corresponding to the next requester identifier. 

16. The arbitration mechanism of claim 15 wherein each priority vector has a number 
of requester identifiers exceeding the number of requesters in the respective combination 
of requesters. 

17. The arbitration mechanism of claim 15 wherein for each requester having a 
number of requester identifiers greater than one in one of said priority vectors, the 
corresponding requester identifiers not all being contiguous in the sequence of requester 
identifiers of said one of said priority vectors. 

18. The arbitration mechanism of claim 15 furth^ compriang a processor that sets 
the total number of requester identifiers in each priority vector and sets the number of 
requester identifiers corresponding to any given requester in each priority vector. 

19. An arbitration mechanism comprising: 
a register for holding a sequence of requester identifiers, said register including 

requester identifiers corresponding to each requestor of a combination of requesters, 
25 wherein the number of requester identifiers in said register exceeds the number of 
requesters in said combiaation; 

a pointer for pointing to one of the requester identifiers in said register; and 
a selector, responsive to requests fi:om the requesters in the combination of 
requesters, for awarding priority to the requester corresponding to the requester identifier 

11 
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being pointed at by said pointer; and 

means for shifting said pointer along the sequence of requester identifiers. 

20. The arbitration mechanism of claim 19 wherein said pointer shifts sequentially 
5 through said sequence of requester identifiers in a wrap aroimd manner. 

21. The arbitration mechanism of claim 19 farther comprising a plurality of said 
registers, each including requester identifiers corresponding to a different combination of 
requesters. 

10 

22. The arbitration mechanism of claim 21 wherein said selector responds to 
requests from a given combination of requesters by awarding priority using the register 
having requester identifiers corresponding to the given combination of requesters. 

15 23. A data processing system comprising: 

a resource; 

a plurality of requesters; 

an arbiter in communication with said plurality of requesters, said arbiter 
including: 

20 a plurality of priority vectors, each providing a sequence of requester 

identifiers, each requester identifier corresponding to one of said requesters, the 
requester identifiers in each priority vector corresponding to requesters from a 
different combination of requesters; 

a selector, responsive to requests for access from the requesters in 

25 a given combination of said requesters, for ascertaining a next requester 

identifier in sequence in the priority vector corresponding to the given 
combination of requesters and awarding priority to the requester 
corresponding to the next requester identifier. 

30 24. The data processing system of claim 23 wherein each priority vector has a 

12 
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number of requester identifiers exceeding the number of requesters in the respective 
combination of requesters. 

25. The data processing system of claim 23 wherein for each requester having a 
5 number of requester identifiers greater than one in one of said priority vectors, the 

corresponding requester identifiers not all being contiguous in the sequence of requester 
identifiers of said one of said priority vectors. 

26. The data processing system of claim 23 further comprising a processor that sets 
10 the total number of requester identifiers in each priority vector and sets the number of 

requester identifiers corresponding to any given requester in each priority vector. 

02442/00102 178719.1 
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